New DOORS 9.2 Undocumented DXL Functions

I have been working on integrating our custom DXL code into the DOORS 9.2 client. I noticed LS_ , NLS_ , and NLSTEMP_ functions seem to be new and are use throughout the client DXL code. Does anyone have any information about these functions?

Thanks,
Lee
Lee_Bost - Mon Sep 28 11:23:07 EDT 2009

Re: New DOORS 9.2 Undocumented DXL Functions
llandale - Fri Nov 13 09:48:07 EST 2009

I see these in the v9.2 doors.exe, meaning they are basic 'perms':

string getLocalizedString(string, string) 
string NLSTEMP_(string)
string NLS_(string)
string LS_(string, string, string)     // lsResource 
string LS_(string, string)
 
The one parameter calls return the input string. (NLSTEMP_ and NLS_)
The two/three parameter callsm return the 2nd parameter.


Looking through the deployed code, I see that an NLS_ call is usually the 2nd parameter of an LS_ call.

I speculate, and hope others can chime in:

'LS' is apparently 'LocalizedString'.
'Temp' is I presume like tempStringOf(Buffer), string conversion that doesn't eat up string table space.
'N' is perhaps 'Non'.

I guess: this is all an attempt to reduce wasted string table space, where these strings exist only once and the doors string table does NOT grow slowly and steadily over time, the more you use DOORS.

 

 

  • Louie

 

 

Re: New DOORS 9.2 Undocumented DXL Functions
Mathias Mamsch - Sat Nov 14 16:02:05 EST 2009

llandale - Fri Nov 13 09:48:07 EST 2009

I see these in the v9.2 doors.exe, meaning they are basic 'perms':

string getLocalizedString(string, string) 
string NLSTEMP_(string)
string NLS_(string)
string LS_(string, string, string)     // lsResource 
string LS_(string, string)
 
The one parameter calls return the input string. (NLSTEMP_ and NLS_)
The two/three parameter callsm return the 2nd parameter.


Looking through the deployed code, I see that an NLS_ call is usually the 2nd parameter of an LS_ call.

I speculate, and hope others can chime in:

'LS' is apparently 'LocalizedString'.
'Temp' is I presume like tempStringOf(Buffer), string conversion that doesn't eat up string table space.
'N' is perhaps 'Non'.

I guess: this is all an attempt to reduce wasted string table space, where these strings exist only once and the doors string table does NOT grow slowly and steadily over time, the more you use DOORS.

 

 

  • Louie

 

 

lol, if this is an attempt to not waste string space, why are the functions returning "strings".

Localized Strings are normally used to have different languages in your code, the content is assigned at runtime regarding on your site parameters (e.g. system language).

If IBM would start trying to fix all the crap in the DXL language it would be very costly. Example: Can you tell me another language that uses an arbitrary constant for uninitialized variable values?
 

int v  // uninitialized ...
int *rv  = &v
print "Uninitialized Value: " (*rv) "\n"
int x = -2023406816   // uninitialized value - 1
print "X = " x "\n"
x++
print "X = " x "\n"   // this fails with "x is not initialized"

 


And for everyone who is wondering why this arbitrary constant: -2023406815 = 0x87654321

Regards, Mathias

 

Re: New DOORS 9.2 Undocumented DXL Functions
Tony_Goodman - Thu Dec 30 16:09:08 EST 2010

Mathias Mamsch - Sat Nov 14 16:02:05 EST 2009

lol, if this is an attempt to not waste string space, why are the functions returning "strings".

Localized Strings are normally used to have different languages in your code, the content is assigned at runtime regarding on your site parameters (e.g. system language).

If IBM would start trying to fix all the crap in the DXL language it would be very costly. Example: Can you tell me another language that uses an arbitrary constant for uninitialized variable values?
 

int v  // uninitialized ...
int *rv  = &v
print "Uninitialized Value: " (*rv) "\n"
int x = -2023406816   // uninitialized value - 1
print "X = " x "\n"
x++
print "X = " x "\n"   // this fails with "x is not initialized"

 


And for everyone who is wondering why this arbitrary constant: -2023406815 = 0x87654321

Regards, Mathias

 

Did anyone find out any more about these intriguing perms?

Tony

Re: New DOORS 9.2 Undocumented DXL Functions
Mathias Mamsch - Thu Jan 06 16:57:58 EST 2011

Tony_Goodman - Thu Dec 30 16:09:08 EST 2010
Did anyone find out any more about these intriguing perms?

Tony

Hey Tony,

as Louie already said, the perms
 

string NLSTEMP_(string s)
string NLS_(string s)

 


do nothing, but returning the parameter you pass to them. Maybe they have been used to give them a function later, but at the moment they are pretty useless.

The perms

 

 

string LS_ (string key, string fallback, string repository) 
string LS_ (string key, string fallback)                    // repository defaults to 'core' repository
string getLocalizedString (string key, string fallback)     // exactly the same as LS_ (in DOORS 9.2) !!



will search the language repository 'repository' for a string with the key 'key'. If the key is found, then the value from the repository is used, otherwise the 'fallback' string is returned. The repositories can be found in the DOORS language directory. With my DOORS 9.2 I see two repositories (each one a directory) shipped 'core' and 'DXL'. Each one contains a binary resource file containing the strings. The repositories are taken from the open source project ICU (International Components for Unicode) , a project IBM is actively supporting, I think. A good choice regarding DOORS 10, since ICU exists in a C and a Java version. So on the web site you can probably find the description of the resource file format.

Example:



 

 

string x 
 
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "DXL")
print "Confirm DXL: " x "\n" // prints 'confirm' on my english installation 
 
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "core")
print "Confirm core: " x "\n" // the string 'confirm' is also in the core repository
 
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "no such rep")
print "Confirm 'no such rep': " x "\n" // fallback since repository does not exist
 
x = LS_("no_such_key",NLSTEMP_("fallback :-("), "DXL")
print "No such key: " x "\n" // fallback since repository does not exist



Regards, Mathias



 

 

 


Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Re: New DOORS 9.2 Undocumented DXL Functions
Stefanhunsicker - Thu Feb 03 06:48:47 EST 2011

Mathias Mamsch - Thu Jan 06 16:57:58 EST 2011

Hey Tony,

as Louie already said, the perms
 

string NLSTEMP_(string s)
string NLS_(string s)

 


do nothing, but returning the parameter you pass to them. Maybe they have been used to give them a function later, but at the moment they are pretty useless.

The perms

 

 

string LS_ (string key, string fallback, string repository) 
string LS_ (string key, string fallback)                    // repository defaults to 'core' repository
string getLocalizedString (string key, string fallback)     // exactly the same as LS_ (in DOORS 9.2) !!



will search the language repository 'repository' for a string with the key 'key'. If the key is found, then the value from the repository is used, otherwise the 'fallback' string is returned. The repositories can be found in the DOORS language directory. With my DOORS 9.2 I see two repositories (each one a directory) shipped 'core' and 'DXL'. Each one contains a binary resource file containing the strings. The repositories are taken from the open source project ICU (International Components for Unicode) , a project IBM is actively supporting, I think. A good choice regarding DOORS 10, since ICU exists in a C and a Java version. So on the web site you can probably find the description of the resource file format.

Example:



 

 

string x 
 
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "DXL")
print "Confirm DXL: " x "\n" // prints 'confirm' on my english installation 
 
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "core")
print "Confirm core: " x "\n" // the string 'confirm' is also in the core repository
 
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "no such rep")
print "Confirm 'no such rep': " x "\n" // fallback since repository does not exist
 
x = LS_("no_such_key",NLSTEMP_("fallback :-("), "DXL")
print "No such key: " x "\n" // fallback since repository does not exist



Regards, Mathias



 

 

 


Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Hi all,
has anybody found a way to use this feature in own DXL scripts?
Every .res file put in a new subfolder of the "language" directory seems to be ignored ...
Thanks and best regards,
Stefan

Re: New DOORS 9.2 Undocumented DXL Functions
Mathias Mamsch - Thu Feb 03 18:56:09 EST 2011

Stefanhunsicker - Thu Feb 03 06:48:47 EST 2011
Hi all,
has anybody found a way to use this feature in own DXL scripts?
Every .res file put in a new subfolder of the "language" directory seems to be ignored ...
Thanks and best regards,
Stefan

Hmm ... Trying with the ICU tools, it seems to work very nicely. Here is a little walkthrough:

1. Download the ICU 4.0 binary release from the ICU website:
http://download.icu-project.org/files/icu4c/4.0.1/icu4c-4_0_1-Win32-msvc8.zip

2. Create a two language for the languages you want to use, e.g.:
Create a file en.txt:

en {
  key1 { "german language, hard language" }
}


Create another file de.txt

 

de {
  key1 { "Deutsche Sprache, schwere Sprache" }
}



Extract the ICU binaries, go to the 'bin' directory, copy both text files there and execute:



 

 

genrb -d . de.txt en.txt



This should have create two files 'de.res' and 'en.res' in the 'bin' directory.

3. Create a new Directory "MyRepo" in the languages directory. Put the de.res and en.res inside there.

4. Execute the following DXL program:



 

 

string x = LS_("key1","fallback", "MyRepo")
print "The string is: " x "\n"



This should print out the string depending on your language (german or english). I appended the res files in a zip file, so if you want you can try with them.

Hope this helps, regards, Mathias



 

 


Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 


Attachments

attachment_14578658_res.zip